The present specification relates to data processing and data objects.
To manage its operations, an enterprise can typically include multiple computing systems, for example, one for customer relationship management, one for product lifecycle management, one for supply chain management, and one for manufacturing. Each of these systems can include one or more applications, each of which is typically configured to perform one or more tasks. The systems of an enterprise may be implemented with different technology stacks, especially when they are purchased from different vendors. A technology stack includes layers of software, for example, applications, application program interfaces, and protocols. Examples of technology stack include, a JAVA stack, a C++ stack, and an ABAP stack. Moreover, one or more of the systems may implement a business process that involves a computing system of another enterprise.
The applications of one of the above-described systems can process, store, and provide data, which can include, by way of example, data objects and business objects. Data objects are generally elements for information storage in object-oriented computing systems. Data objects can describe the characteristics of an item using a series of data fields that, for example, can correspond to described characteristics. One example of a data object is a business object, which is typically used in data processing to describe the characteristics of an item or a process related to the operations of an enterprise. A business object can represent, by way of example, a document, a sales order, a product, a piece of manufacturing equipment, an employee, and even the enterprise itself.
The data can be of a particular type. There are simple data types and complex data types. Examples of data types that are simple include but are not limited to an alphanumeric string, an integer, and a floating point decimal number. Examples of data types that are complex include but are not limited to attributes of a business object and the business object itself.
In conventional systems, an application of a system is usually associated with one or more repositories that are local to the system, and a repository local to the system can be associated with more than one application of the system. A repository is generally a collection of object definitions, for example, definitions for data types, object properties and behavior, services associated with an object, and properties of software entities, that are used by the one or more applications with which the repository is associated. An application needs the definitions stored in the local repository and usually cannot function properly without them. Consequently, at design time, a stage when the application is being designed and built, a developer must usually be aware of the local repositories that are expected to be available to the application and include references to these repositories. Furthermore, when there are more than one local repository, the developer must usually specify which definitions are to be included in which local repository.
An application can also be associated with a repository that is not local to the system in which the application operates. Such a repository is referred to in the instant specification as an external repository. In this case, the developer must usually, at design time, be aware of this requirement and include, in the code of the application, a reference to the external repository. Furthermore, when the system in which the external repository is located is implemented with a technology stack that is different from the technology stack of the application, the developer must also be aware of the different requirements of the two technology stacks and include, in the code of the application, instructions for accessing information from the technology stack of the local repository and the technology stack of the external repository. Awareness of the landscape in which the application will operate is, thus, necessary at design time.